Secure Medical Device Software Development Attestation

As a medical device developer, you are probably concerned about your current project: Are you performing all the cybersecurity tasks and creating all the required documentation to achieve premarket approval or clearance from the FDA? For the record, being concerned is absolutely justified.

What if I told you there is another government agency (actually several, including CISA, OMB, and NIST) with which you also have to comply if you intend to sell your medical devices to the nation’s largest hospital network? The Veterans Health Administration (VHA) is the largest integrated healthcare system in the United States, providing care at 1,321 healthcare facilities—including 172 VA Medical Centers and 1,138 outpatient sites of care of varying complexity (VHA outpatient clinics)—to over 9 million veterans enrolled in the VA healthcare program.¹

Further, it isn’t just within these facilities where your device is being used. Selling to the VHA also includes the U.S. Military—a smaller, but no less desirable market. I’d be willing to guess your sales team is very interested in including the VHA as among your potential clients.

The other agency to which I am referring is the U.S. Cybersecurity & Infrastructure Security Agency (CISA). Specifically, any medical device firm seeking to sell to the VHA will need to complete the “Secure Software Development Attestation Form,” which was released on March 11, 2024.²

This form is required as a result of three different White House documents, starting with Executive Order 14028—Improving the Nation’s Cybersecurity—which outlines the federal government’s approach to reducing cybersecurity supply chain risks. The subsequent memorandums are Office of Management and Budget (OMB) M-22-18—Enhancing the Security of the Software Supply Chain through Secure Software Development Practices—and its updated version M-23-16.³ Together, these mandate that federal agencies may purchase “the software” only if the developer attests to following the majority of rules in the National Institute of Standards and Technology (NIST) SP 800-218—Secure Software Development Framework (SSDF).⁴

Impact for Medical Device Manufacturers

By now, you’re likely asking, “Does this apply to my medical devices?” The answer is a resounding “Yes.” M-23-16 presents the following qualifier: “For the purposes of M-22-18 and this memorandum, “software” includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.”

From a timeline perspective, the memorandum states, “M-22-18 requires each Federal agency to collect attestations from producers of software used by the agency if that software was developed after September 14, 2022, the effective date of M-22-18. Agencies are also required to collect attestations from producers of software developed prior to September 14, 2022, if that software is used by a Federal agency and either: (1) is modified by one or more major version changes after September 14, 2022, or (2) is a hosted service that deploys continuous updates.”

This attestation form needs to be signed by the manufacturer’s CEO or their designee. That person must be an employee of the manufacturer and have the authority to bind the company to this form. This process raises the responsibility of security to the highest level of the manufacturer.

The form itself does include somewhat of an alternative: “In the event that an agency cannot obtain a completed self-attestation from the software producer, an agency may still decide to use the producer’s software if the producer identifies the practices to which they cannot attest, documents practices they have in place to mitigate associated risks, and submits a plan of actions and milestones (POA&M) to the agency.” Providing this information, however, may be more work for the manufacturer than simply complying with the NIST SSDF requirements and completing the attestation form.

Once completed, the attestation form can be submitted to an online OMB repository (instructions are provided) or emailed directly as a PDF to the agency in question (e.g., VA Hospital) before the sale to the agency can be accomplished. The signory must be certain the manufacturer is in fact following the SSDF requirements, as false claims can be prosecuted by the DOJ rather severely.⁵

SSDF Requirements

The attestation form does not require compliance with the entire SSDF. Instead, it indicates the minimum requirements that must be attested to, while several are omitted from the list. The company must comply with the following 29 requirements in the SSDF.

PO.1.1
PO.1.3
PO.3.1
PO.3.2
PO.3.3
PO.4.1
PO.4.2
PO.5.1
PO.5.2
PS.1.1
PS.2.1
PS.3.1
PS.3.2
PW.2.1
PW.4.1
PW.4.4
PW.5.1
PW.6.1
PW.6.2
PW.7.1
PW.7.2
PW.8.1
PW.8.2
PW.9.1
PW.9.2
RV.1.1
RV.1.2
RV.2.1
RV.3.3

I encourage you to visit the actual Secure Software Development Framework Version 1.1 document⁶ to gain further insight into the details of each requirement and how it will impact your organization. While 29 requirements are specified, that still leaves 13 that were not included. The omission of some of these is odd, such as performing threat modeling (PW 1.1) (not required for attestation).

Conclusion

How will this play out? Will the particular agencies actively enforce this? My guess is they most likely will, as this is cybersecurity information they can access before making a purchase and something they have wanted for a long time.

Have you updated your security development SOP to align with a secure development framework like ISO/IEC 81001-5-1? Have you also included all the other activities required by the FDA? My best suggestion would be for you to go back and amend your company’s SOP to include support for the 29 SSDF requirements. Only a couple of them will have been properly covered by IEC 810001-5-1 or the FDA. 

References

1. tinyurl.com/mpo240921
2. tinyurl.com/mpo240922
3. tinyurl.com/mpo240923
4. tinyurl.com/mpo240924
5. tinyurl.com/mpo240925
6. tinyurl.com/mpo240926

---

MORE FROM THIS AUTHOR: The Cost of Cybersecurity in Medtech

---

Christopher Gates is the director of Product Security at Velentium and the current co-chair for H-ISAC’s MDSC. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. Gates frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.